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Abstract. Algorithms for laying out large graphs have seen significant progress 
in the past decade. However, browsing large graphs remains a challenge. Ren¬ 
dering thousands of graphical elements at once often results in a cluttered image, 
and navigating these elements naively can cause disorientation. To address this 
challenge we propose a method called GraphMaps, mimicking the browsing ex¬ 
perience of online geographic maps. 

GraphMaps creates a sequence of layers, where each layer refines the previous 
one. During graph browsing, GraphMaps chooses the layer corresponding to the 
zoom level, and renders only those entities of the layer that intersect the current 
viewport. The result is that, regardless of the graph size, the number of entities 
rendered at each view does not exceed a predefined threshold, yet all graph ele¬ 
ments can be explored by the standard zoom and pan operations. 

GraphMaps preprocesses a graph in such a way that during browsing, the geome¬ 
try of the entities is stable, and the viewer is responsive. Our case studies indicate 
that GraphMaps is useful in gaining an overview of a large graph, and also in 
exploring a graph on a finer level of detail. 


1 Introduction 

Graphs are ubiquitous in many different domains such as information technology, so¬ 
cial analysis or biology. Graphs are routinely visualized, but their large size is often 
a barrier. The difficulty comes not from the layout which can be calculated very fast. 
(For example, by using Brandes and Pich’s algorithm m a graph with several thousand 
nodes and links can be laid out in a few seconds on a regular personal computer.) Rather, 
viewing and browsing these large graphs is problematic. Firstly, rendering thousands of 
graphical elements on a computer might take a considerable time and may result in a 
cluttered image if the graph is dense. Secondly, navigating thousands of elements ren¬ 
dered naively disorients the user. 

Our intention is to provide a graph browsing experience similar to that of online ge¬ 
ographic maps, for example, Bing or Google Maps. We propose a set of requirements 
for such a visualization and introduce a method, GraphMaps, fulfilling these require¬ 
ments. GraphMaps renders a graph as an interactive map by displaying only the most 
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Fig. 1: A graplQwith 1436 nodes and 5806 edges, (a) The full view with a standard method which 
draws all nodes and edges regardless of the zoom, (b) The full view rendered by GraphMaps. 
(c) A view with the zoom close to 9.13 with the standard viewing, (d) A view with zoom 9.26 
with GraphMaps. 


essential elements for the current view. We allow fast interactions using standard pan 
and zoom operations. The drawing is visually stable, in the sense that during these op¬ 
erations, nodes do not change their relative positions, and edges do not change their 
geometry. To the best of our knowledge, GraphMaps is the first method having these 
properties. Fig.illustrates the method. 


Related Work. The problem of visualizing large graphs has been extensively addressed 
in the literature, but here we discuss only the approaches most relevant to ours. Most 
research efforts have concentrated on reducing the number of visual elements to make 
node-link diagrams readable. We mention three different approaches. 

Aggregation techniques group vertices and edges of the graph together to obtain a 
smaller graph do). Most techniques compute a hierarchical partitioning and offer in¬ 
teraction to explore different branches of the tree. Early work by Eades and Eeng mi 
proposes 3-dimension visualization to navigate in this tree. Later research d demon¬ 
strated that techniques implementing this approach can scale up to very large graphs 

^ https://github.com/ekoontz/graphviz/blob/master/rtest/graphs/b 1 OO.dot 
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(16 million edges and 200,000 nodes). Similar approaches attempt to give more clues 
about the content of the aggregates. Balzer and Deussen O represent aggregates by 
3-dimensional shapes, whose sizes convey the number of vertices, with bundled edges 
whose thickness indicates the density of the connection. Zinmaier et al. l23]| utilize the 
GPU to create an aggregated image of a large graph, using heatmaps to convey the 
number of vertices and edges in the aggregates. 

While these techniques can scale up to very large graphs, they have several disad¬ 
vantages. Aggregating nodes involves a loss of information concerning intra- and inter¬ 
connectivity. Spatial stability is another issue. The drawing may change dramatically 
when several entities collapse into one, potentially disorienting the user. 

Multiscale techniques allow users to explore the partition hierarchy at different depths. 
These techniques aim at disambiguating the topology induced by aggregating vertices 
and edges together. Auber et al. n propose a clustered multiscale technique, for which 
the interiors of the aggregates are shown at a finer scale. However, aggregated edges are 
shown between clusters, risking misinterpretation. Henry et al. o propose a hybrid 
technique that can only represent one level of clustering. In a similar spirit van Ham and 
van Wijk ca propose an aggregate method in which users can expand one aggregate at 
a time. Henry et al. ca attempt to indicate inter-aggregate connectivity by duplicating 
elements, but their solution only works for a single level of clustering. 

A different technique by Koren et al. ca aims at smoothly integrating the level of 
detail, as opposed to discrete partitioning of the graph. The authors build a hierarchy 
of graphs and, for each viewpoint, construct a smaller graph by “borrowing” parts of 
the corresponding hierarchy levels and adjusting the layout of this smaller graph. The 
strength of this technique is that it avoids potentially misleading partitioning of the 
graph. However, there is a lack of stability: a small change in viewport may lead to a 
large change in the viewed graph. The fisheye technique of the paper may also add a 
spatial distortion, further disrupting the user’s mental map. 

Filtering techniques approach the visualization of large graphs by filtering the ele¬ 
ments rendered in the view. For example, SocialAction ca provides a set of measures 
to rank vertices and edges, rendering node-link diagrams with manageable sizes. A 
related technique by Perer and van Ham d proposes to build a filtered node-link dia¬ 
gram based on the queries made by the user, via the concept of degree-of-interest. The 
principal disadvantage of these techniques is the lack of overview of the entire graph. 
The progressive rendering approach proposed by Auber et al. EEl renders the node¬ 
link diagram entities in order of their importance. The rendering stops when the view 
changes. Given enough non-interaction time, all entities intersecting the viewport are 
rendered. In contrast to the previous filtering techniques, the benefit of this approach is 
to reveal the key features of the graph first. However, the user does not directly control 
the level of detail, which potentially disrupts the experience. 


Design Rationale Motivated by Online Maps. Exploring online geographic maps 
is probably the most common scenario for browsing large graphs. Millions of people 
every day browse maps on their cellular phones or computers for finding a location or 
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driving directions. We decided to search for key ideas used in interactive geographic 
maps that could be applied to browsing general graphs. 

One insight is that showing everything at all times is counterproductive. In a digital 
map on the top level we only see major cities and major roads connecting them. Ob¬ 
jects on finer levels of detail, like smaller roads, are not shown explicitly. They may be 
hinted by using, for example, pre-rendered bitmap tiles. When we zoom in, other, less 
significant features appear and become labeled. Online maps can answer search queries 
such as finding a route from source to destination or showing a point of interest close to 
the mouse position. 


Design goals identified are as follows: 

1. The method should be able to reveal most details of the graph by using only the 
zoom in, zoom out, and pan operations. As we zoom in, more vertices and edges should 
appear according to their importance. Interactions such as node or edge highlighting or 
search by label should help discover further details. 

2. During these operations, the user’s mental map must be preserved. In particular, 
vertex positions and edge trajectories should not change between zoom levels. 

3. In order to limit visual clutter, the number of rendered visual elements at each view 
should not exceed some predefined bound. 


2 Method Description 


The input to the algorithm is a graph with given node positions; the edge routes are not 
part of the input. The output is a set of layers containing nodes and edge routes. Let 
G = (y, E) be the input graph, where V is the set of nodes and E the set of edges. The 
input also includes an ordering of V. This ordering should reflect the relative importance 
of the vertices. If such an ordering is not provided then we can sort the nodes, for 
example, by using PageRank CD , by node degree, or by shortest-path betweenness i). 
Finding a good order reflecting the node importance is a separate problem which is 
outside the scope of this research. Here we look at the node order as input and consider 
V = [i;i,..., i;Ar] to be an array. 

Before giving a detailed description of the algorithm we describe its high level steps. 

We build the layer 0, denoted by Lq, as follows. For some number ko > Owe assign 
nodes ,..., Vk^ to Lq and route all edges ^n) ^ E with m, n < ko. Suppose we 
have already built containing vertices Vj, for j < ki-i. Then, if ki-i < N, that is 
we have vertices that are not assigned to a layer yet, for a number ki > ki-i we assign 
nodes ui,..., u/.. to Li and route all edges {vm, v^) e E with m^n < ki. Otherwise 
we are done. Note that a node can be assigned to several consecutive layers. To achieve 
the assignment we define a function ^ from V to the set {2^, 2^, 2^,... }. The value 
z{v) we call the zoom level of the node. For n G No, the layer contains node v if 
and only if z{v) < 2^. For each layer an edge is represented by a set of straight line 
segments called rails. We define function 2 ; on rails too, but the layer assignment rule 
is different for rails; a rail r belongs to Ln iff z{r) is equal to 2^. 
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Fig. 2: Graph abstract.dot, Qn = 80, Qr — 180. |(a)|The mesh containing node boundaries 
of layer 0 (thick), [(b^ Nodes of layer 0 (green) and rails of edges routed using the mesh in|(a)| 
(black). Adding node 20 would exceed the node quota. The mesh containing rails and node 
boundaries of layer 0 and boundaries of candidate nodes for layer 1 (thick), [(d^ Node 37 has 
inserted nodes 6 and 28 as neighbors. The edges incident to Node 37 are routed through red rails, 
which are new maximal rails. After adding the red rails the upper left tile would intersect more 
than QrIA — 45 maximal rails, (e) Mesh containing rails and node boundaries of layer 1 and 
candidates for layer 2. (f) All nodes and edges are added to layer 2 without exceeding the quotas. 


Calculation of layers. Algorithm [^computes the function z on the nodes and extends 
it to the rails. The flow of the algorithm is illustrated in Fig.[^ 
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Algorithm 1: Setting node zoom levels with rail quota 

SetNodeRailZoomLevelsO 

1 assignedNodes = 0, maximalRails = 0 

2 tileSize = BoundingBox(G), nodeSize = InitialNodeSize, n = 0 

3 while I assignedNodes I < |1/| do 

4 ProcessLayerO 

5 tileSize = tileSize * 0.5, nodeSize = nodeSize *0.5, n = n + l 


ProcessLayerO 
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initialize tileMap with assignedNodes and maximalRails 
candidateNodes = TryAddingNodesUntilNodeQuotaFull(n) 
prevLayerRails = rails of Ln-1, or 0 if n = 0 

M = GenerateMesh(assignedNodes U candidateNodes, prevLayerRails) 
prevLayerRailsUpdated = SegmentsOfMeshOn(M,prevLayerRails) 
z(prevLayerRailsUpdated) = 2^ 
foreach v G candidateNodes do 

rails(i;) = RailsOnEdgeRoutes(i;, assignedNodes, M) 

maximalRailsOfV = FindMaximalRails(rails(i;)) 

if adding all maximalRailsOfV to Ln exceeds rail quota then return 

setz(i;) = z(rails(i;)) = 2'^ 

update tileMap with v and maximalRailsOfV 

maximalRails = maximalRails U maximalRailsOfV 

assignedNodes = assignedNodes U {u} 


Let B be the bounding box of G with width w and height h. For ij,n G No we 
define T-^ as the rectangle with width = rc/2^, height hn = h/2^ and the bottom 
left comer with coordinates x = u ^ i • and y = v j • hn, where {u,v) is the left 
bottom corner of B. We call a tile. The algorithm is driven by positive integers Qn 
and Qr, which we call node and rail quota, respectively. We say that tile Tfj exceeds 
node quota Q at if it intersects more than Qn nodes of layer n. 

To work with the rail quota Qrwq need the following definition. For a set of rails 
R and a rail r G we call r maximal in i? if r is not a sub-segment of any other rail 
in R. During the algorithm we maintain the set of maximal rails among the set of rails 
already assigned to layers and count intersections between the tiles and the maximal 
rails only. The union of all maximal rails will always form the same set of points as 
the union of all rails created so far. Tile Tfj exceeds rail quota if it intersects more than 
Qr/^ rails which are maximal among all rails of layer n and below. Assume both Qn 
and Qr are divisible by 4. 

The outer loop of Algorithmic in line works as follows. Starting with n = 0, each 
call to ProcessLayer in line tries to greedily assign the nodes to the current layer. 
Each such attempt starts with the first unassigned node in V. Procedure ProcessLayer 
terminates if adding the next node in V and its edges incident to already assigned nodes 
would exceed the node or rail quota of some tile. 
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After calling ProcessLayer tile dimensions and the node size become twice smaller, 
and a new attempt starts for n + 1 in line The algorithm stops when all nodes are 
assigned to a layer. Fig. [^illustrates Algorithmfor graph ahstract.do^Wiih 47 nodes, 
labeled from 0 to 46 according to their order in V. 

In line tileMap is a map from Nq to Nq. If for some n we have tileMap(i, j) 
= (r, k), then r nodes in Ln and k maximal rails intersect T-^. 


Let us now consider ProcessLayer forn = 0. For this case the domain of tileMap 
is {(0,0)}. The sets assignedNodes and maximalRails are empty, and there is only 
one tile Tq Q’ which has the size of B (blue in Fig. [^ and |^. After executing linej^ 
the set candidateNodes contains the first Qn/^ nodes of F (green in Fig. [2^ The 
boundaries of these nodes are represented by regular polygons (thick in Fig. |2a|) and 
used to generate a triangular mesh M. The mesh is a constrained triangulation in a 
sense that any straight line segment of the input can still be traced in M although it can 
be split into several segments. The edges with both endpoints in candidateNodes are 
routed on M. 

In the i + 1-th iteration of the loop in line the algorithm tries to add node i, 
while nodes 0,..., i — 1 have already been added to Lq, and tileMap(0,0) = (i, k), 
where k < Qr/A is the number of rails used by edges routed so far. All these rails are 
maximal rails by construction. 

In line the routes of edges from node i to nodes 0,..., i — 1 are computed 
as shortest paths on M, and the set rai\s(v) is the set of all rails of these routes. In 
line [T^ we find maximalRailsOfV, the rails from rails(^’) which are maximal with 
respect to the set maximalRails U rails(v). In the case of n = 0 they are all the rails of 
rails(i;) \ maximalRails. For n > 1, these are the rails from rails(i;) covered by no rail 
from maximalRails. In Fig.|^ such maximal rails for node 37 are drawn red. 

If Tq 0 still contains no more than Qr/^ rails after adding maximalRailsOfV, then 
node i is added to Lq. Otherwise, ProcessLayer terminates. In Fig. 2b all(5iv/4 = 20 
candidate nodes and the rails on the corresponding edges could be added to Lq. 

The procedure works similarly for n > 1. One notable difference is that rails 
from Ln-i are passed as input to the mesh generator in addition to the boundaries 
of the appropriate nodes in line[^ For more details we refer to the proof of Lemmal^in 
the appendix. Fig.[^ ... ,[^show ProcessLayer forn = 1, 2. 


Using the layers during the visualization. Let Ff be a rectangle. We denote by w{H) 
the width of H and by h{p) the height of H. Recall that B is the bounding box of G. 
Then the zoom level of H to B is the value 1{H) = min{^^, 

Let K be the transformation matrix from the graph to the user window W. Then 
the rectangle P = K~^{W), where K~^ is the inverse of K, is the current viewport. 

To decide which elements of G are displayed to the user, we find the zoom level Z = 
1{P) and set the layer index n = max(0, [log 2 Z\). Finally, the elements displayed to 
the user are all the nodes and rails of layer Ln intersecting P. We show in the appendix 
in Theorem that, by following this strategy, we render at most Qn nodes, and the 
rendered rails can be exactly covered by at most Qr maximal rails. 


^ https://github.com/ekoontz/graphviz/blob/master/rtest/graphs/abstract.dot 








Edge routing and overlap removal. Consider the nodes of Lq . To construct a graph 
on which the edges are routed, we first create a regular polygon for each vertex. Then, 
we generate a triangular mesh using the Triangle mesh generator by Shewchuk |[2Ql . By 
inserting additional vertices Triangle creates meshes with a lower-bounded minimum 
angle, which implies the upper-bounded vertex degree. Each edge between a pair of Lq 
nodes is then assigned the corresponding Euclidean shortest path in the mesh, which is 
computed using the ^4* algorithm. Mesh segments lying on such paths become rails of 
Lq and the remaining mesh segments are discarded. 

We now proceed with edge routing for for n > 1. Consider Procedure Pro- 
cessLayer. Since the initial node placement did not take edge trajectories into account, 
at the beginning of the procedure some unassigned nodes might overlap the entities of 
Ln-i. We move these nodes away from their initial positions to resolve these overlaps, 
but this way we might create new overlaps with the nodes that are not assigned to a 
layer yet. 

The overlap removal process happens before line |7] We follow the metro map la¬ 
beling method of Wu et al. {2^ . All line segments and bounding boxes of fixed nodes 
are drawn on a monochromatic bitmap and the image is dilated by the diameter of a 
node on L^. To define a position for a candidate node v at which it does not overlap 
already placed nodes or rails, we find a free pixel p in the image, ideally close to the 
initial location of v. We draw a dilated v at p and proceed with the next candidate, etc. 

To generate a graph for edge routing on we use the bounding polygons of nodes 

from candidateNodes and the nodes of and the rails of Ln-i, as the input seg¬ 

ments for Triangle. Already routed edges maintain their trajectories, while edges in¬ 
cident to a node not belonging to L^-i are routed over the triangulation created by 
Triangle in line[^ To create the bundling effect by reusing existing rails, we slightly 
reduce their weights during routing. 

Pre-rendered tiles. To help users gain spatial orientation, we hint the nodes which are 
not yet visible at the current zoom level, but will appear if we zoom in further. Eor this 
purpose we create and store on the disk the images of some graph nodes and use them 
as the background. The images are generated very fast and are loaded and unloaded 
dynamically by a background thread to keep the visualization responsive. Eor more 
details see Section [53] of the appendix. 

Interaction. We define several interactions in addition to the zoom and pan. Clicking 
on a node (even if it is hinted, but not visible yet) highlights all edges incident to it and 
unhides all adjacent nodes. The highlighted elements are always shown regardless of 
the zoom level. Clicking on a rail highlights the most important edge passing through 
it, and unhides the edge endpoints. Additionally, nodes can be searched by substrings 
of their labels. 

3 Experiments 

Visualizing and evaluating clusterings. The test graph of our first experiment is the 
Caltech graph, which was used by Nocaj et al. ini. It is the graph of Eacebook friend- 
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ships at California Institute of Technology from September 2005 and contains 769 
nodes and 16k edges 1^ . The nodes are labeled by class year and residence, or house, 
of the corresponding student, and colored by the house. The label 0 denotes missing 
data. 



Fig. 3: Caltech graph on four different zoom levels visualized using our approach. 


A computer science researcher, with focus on clustering algorithms, used GraphMaps 
to browse this graph. He was interested in discovering the connectivity structure of the 
graph, e.g., which houses or years have strong ties. The researcher’s tool of choice 
for visualizing clusterings was Gephi ID The node layout was computed by a force- 
directed layout algorithm applied to the Simmelian backbone of the graph, as proposed 
by Nocaj et al. ifTTI . The result is shown in Fig.|^ The same initial layout was used as 
input for our algorithm. The resulting drawing on four different zoom levels is shown 
in Fig. 1^ 

The user noted that the view in Fig. 4a was too dense and gave no insight into the 
graph connectivity. On the other hand, he found our result in Fig.j^less cluttered. User 
commented that, by looking at the edge routing created by GraphMaps, one may think 
that two nodes are connected by an edge, when, in fact, they are not. However, by using 
additional interactions besides zoom and pan, e.g., edge highlighting, the connectivity 
can be understood. 











(a) 


(b) 


(c) 


Fig. 4: [^Caltech graph visualized using Gephi. |(b)||(c)| showing neighbors of node “165 2007” 
(leftmost orange node surrounded by green nodes) using Gephi and our tool. 


One interaction mode that the user tested for both tools was selecting all neighbors 
of a node. In Gephi, when hovering the mouse over a node, all non-incident edges and 
non-adjacent nodes are grayed out; see Fig. ^ In our method, when clicking on a node, 
routes of all its incident edges are highlighted and, additionally, all adjacent nodes are 
shown, regardless of the zoom level; see Fig. According to the user, both meth¬ 
ods provided satisfactory results. He noted that GraphMaps, by using edge bundling, 
provides a tidier picture than Gephi. 

For dense graphs, like Caltech, the user would prefer to view the neighbors of a 
node in GraphMaps. The user commented that, contrary to Gephi, GraphMaps exposes 
the most important nodes and their labels in a readable fashion. 


Experiments with other graphs. In the video at http: //idrv.ms/lisBEVh we 
demonstrate browsing the graph “composers’]^ with GraphMaps. The nodes of the graph 
represent the articles on Wikipedia on composers, and the edges represent Internet links 
between the articles. In the video we demonstrate the user interactions that help us to 
explore the graph. 

When browsing the graph of Info Vis coauthors, created from ACM data, another 
user was able to notice two groups of coauthors, one connected to Peter Eades, and 
another one to Ulrik Brandes and Michael Goodrich. By selecting ah direct neighbors 
of Peter Eades, the user was able to see that only one member of the second group, 
Roberto Tamassia, has a paper with Peter Eades; see Eig.[^in the appendix. Eurther 
analysis showed that, according to the data set, Roberto Tamassia, is the only author 
with coauthors from both groups. GraphMaps enabled the user to gain insights on the 
graph structure. 


Running time. GraphMaps processes a graph with 1463 nodes and 5806 edges for 1 
minute, a graph with 3405 nodes and 13832 edges for 130 seconds, and a graph with 

^ http://www.graphdrawing.de/contest201 l/topic2-2011 .html 
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38395 nodes and 85763 for less than 6 hours. The experiments were done on an HP- 
Z820 with Intel Xeon CPU E5-2690 under Windows 8.1. The required memory was 16 
GB. The current bottleneck in performance is the edge routing. We hope to speed up 
the edge routing by using parallel processing. 


The sources of GraphMaps. GraphMaps is implemented in MSAGL, which is avail¬ 
able as Open Source at github.com/Microsoft/automatic-graph-layout. 


4 Discussion 

The users of GraphMaps appreciate its aesthetics and the similarity to browsing online 
maps. GraphMaps helps in gaining the first impression of the graph structure and, in 
spite of the fact that precise knowledge of the connectivity cannot be obtained with 
GraphMaps by zooming and panning alone, additional interactions allow answering the 
queries as, for example, finding if two nodes are direct neighbors. A current shortcom¬ 
ing of GraphMaps is that the direction of the edges is lost. It happens for other methods 
as well, when edges are bundled. Solving this issue is a possible future work item. 
The labeling algorithm needs improvement, since it does not always respect the node 
ranking and does not always utilize free space well enough. 


Future work. Currently we cannot guarantee that our layer generation algorithm al¬ 
ways reaches the end, although, in all our experiments it did. Creating a version of the 
algorithm which provably stops, or, even better, guarantees that the number of generated 
layers is within predefined bounds, is a very interesting problem. 

Another problem is finding a node placement working nicely with the node ranking 
and suitable to assigning the nodes to the layers. Ideally, such a layout algorithm is 
aware of the edge routing too, and avoids the overlap removal step. 


Acknowledgements. We are grateful to Roberto Sonnino for the useful discussions 
on the rendering of the tile images in a background thread, and to Itzhak Benenson for 
sharing with us his ideas on the visualization style. 
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5 Appendix 



(a) 


Fig. 5: We can establish that Roberto Tamassia is the only coauthor of Peter Fades in the right 
group 


5.1 Proof that quotas are satisfied 

Here we repeat the definitions from Section for the sake of convenience. Let K be 
the current transformation matrix from graph G to the user window rectangle W, and 
let rectangle P = K~^{W) denote the rectangle W mapped to the graph coordinates. 
Let B be the bounding box of G, and ic, are the width and the height of a rectangle, 
respectively. We then define the current zoom level Z as Z = 1{P). Recall that 1{P) 
is defined as 1{P) = min{^|^, We choose n = max(0, [log 2 Z\) and render 

elements of intersecting P. We need to prove that we do not exceed the quotas when 
rendering. 

In general, let H be any rectangle and let n{H) = max(0, [log 2 Let Vh = 

{v G V,z{v) < 1{H) Sindv intersects H}. Set Vp represents all the nodes that are 
rendered for the current view. Let R be the set of all rails on all layers. Let Rp = {r G 
R : z{r) = 1{H) and r D H ^ 0}. In this notation, the set Rp represents all the rails 
rendered for viewport P. 
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For each rail r G R let m{r) G R denote the maximal rail of R containing it. Of 
course, r = m{r) for a maximal rail. 

Let Rp^^ = {m{r) e R : r e Rp}. Rendered on the plain, the rails of Rp^^ 
cover the drawing of rails of Rp, because each rail is either maximal or is contained in 
a maximal rail. 


Lemma 1. Algorithm^sets z in such a way that for any n^i^j and T = we have 
I^tI < QN/^and < Qr/A. 

Proof For the first call to ProcessLayer, we have n = 0. We prove the statement by 
induction. Consider Procedure ProcessLayer for zoom level 1 = 2^^, n = 0. The sets 
assignedNodes and maximalRails are empty, and there is only one tile T = Tq q, 
which has the size of B. After executing line [7] the set candidateNodes contains the 
first Qn/^ nodes in V. Adding all candidate nodes to T would not break its node 
quota. All rails added to zoom level 2^ are maximal rails. Due to the if statement in 
linep~5| candidate v is added to T in lineonly if T would contain at most Qr/4: rails 
afterwards. 

Suppose the statement holds forn — 1, where n > 1, and let us prove it for n. To do 
so, we first give a more detailed description of the n + 1-th execution of ProcessLayer 
than in Section]^ In lineassignedNodes is the set of nodes of layer The set 

maximalRails is a set of rails maximal in R' and covering R' completely, where R' is 
the set of rails of layers Lq, ..., We initialize tileMap by counting for each tile 

the number of nodes from assignedNodes and the number of rails from maximalRails 
intersected by it. In line nodes in y \ assignedNodes are iteratively added to the 
set candidateNodes, as long as each tile intersects no more than Qn/^ nodes from 
V' := assignedNodes U candidateNodes. Then, a constrained triangular mesh M is 
built on all rails of Ln-i and boundaries of nodes from V'. In linesand pT| the rails 
of layer are added to layer after possibly being subdivided by M. Further on 
the algorithm adds candidateNodes and the rails on the corresponding edges to as 
long as each tile intersects no more than Qr/A maximal rails. 

To get a better understanding of the algorithm, consider Fig. Here, we have 
n = 1, and set candidateNodes is equal to {20,..., 46}, representing all the remain¬ 
ing nodes to assign. Thus, all node boundaries and all the rails of the routes between 
nodes 0,..., 19 from Lq, see Fig. ^ are passed to the mesh generator. Nodes 20,..., 36 
are inserted. When adding node 37 and the corresponding rails the rail quota is ex¬ 
ceeded, so no addition happens. Finally, forn = 2, the remaining nodes 37,..., 46 are 
added to L 2 . 

Going back to the proof, us now prove the statement for n + 1. For a tile T of 
level n, we have /(T) = 2'^ on the n + 1-th call to ProcessLayer. Tile T = T- 




by construction, is a subset of the tile T' = By the induction hypothesis, T' 

intersects at most Qat/ 4 nodes, and \Rp^^\ < Qr!^. After the insertion in line|^ only 
assignedNodes are on and T intersects at most Qn nodes of 

Again, candidateNodes contains a set of nodes which can be inserted without 
breaking node quota of any tile on level 2'^. For nodes V' :=assignedNodes UcandidateNodes 
we pass the bounding polygons of the current node size as well as rails of level 2'^~^ 
(prevLayerRails) to the mesh generator, which then creates a triangular mesh M. 
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In lines 1^ and [TT] the set prevLayerRailsUpdated contains the segments of M 
which are covered by rails in prevLayerRails and we do not have new maximal rails. 
Thus, directly after line[^ C and contains at most Qr/^ elements. 

Similarly to level 1, the algorithm attempts to add candidateNodes and maximal 
rails covering the corresponding edges to tileMap, as long as each tile contains no 
more than Qr/4: maximal rails. Because of the guarding if statement in line 15 we will 
not overfill the quotas for T after inserting each candidate node v and maximalRail- 
sOfV in line[^ Thus, the quotas hold for T on level 2'^. □ 


Theorem 1. On termination, Algorithm^defines the layers in such a way that |Vp| < 
Qn and\Rf^^\ < Qr. 


Proof. Let n = n{P) = max{0, [log 2 1{P)\ }• By Lemma[^ each tile of Ln intersects 
not more than Qn/4 nodes of and not more than Qr/4 of maximal rails from 
The tile’s dimensions in Ln are w{B)/2^ and h{B)l2^. If we prove that P 
intersects not more than four tiles of Ln, then the theorem follows. For n = 0 we have 
only one tile on Lq, and the theorem holds. 

Let n > 0. We show that P “is not greater than” a tile of Ln, that is, u;(P) < 
w{B)/2^ and h{P) < h{B)l2^, and hence, P cannot intersect more than four tiles of 
Lri' 

By the definition of 1{P), we have 1{P) < w{B)/w{P) and 1{P) < h{B)/h{P). 
Let us prove that w{P) < w{B)/2^. The proof that h{P) < h{B)/2^ is similar. Since 
n > 0, we have n = [log 2 1{P)\ < log 2 Therefore, 2^ < 1{P) < w{B)/w{P), 
and w{P) < w{B)/2^. The theorem follows. 


5.2 Node labeling 

We render nodes as circles and assign them text labels, both of constant height on the 
screen; see Fig. right. To guarantee readability, we aim to avoid overlaps of labels 
with nodes and with each other. For a given view only a subset of visible nodes might 
have visible labels. Our approach makes use of the order of nodes in V and greedily 
tries to label important nodes first. Each node v e V is assigned a value £{v) > z{v) 
and one possible label position p{v)\ left, right, above or below the node circle. The 
label of V is visible if and only if the current viewport intersects the label and if it holds 
Z > l{v), where Z is the current zoom level as defined in Section]^ 

We iteratively consider zoom levels Zi = (5o for i = 0,1, 2,... and some (5o > 0, 
6 > 1, e.g., ^0 = 2“^ and 6 = 2^/^. For fixed Zi, we insert all nodes v with z{v) < Zi 
as well as all assigned labels into an R-tree with sizes corresponding to Zi . Next, for 
yet unlabeled nodes v with z{v) < Zi, we set i{v) = Zi iteratively according to the 
order of nodes in V, as long as no label overlaps arise. As the zoom level grows 
the bounding boxes of the labels and the nodes shrink, so for some, maybe large, i it 
is possible to find p{v) such that the label’s bounding box does not overlap already 
processed nodes and labels. Then, we can insert the label into the tree. When looking 
for p(^) we try to insert the label left, right, above or below the node circle in this order. 

This simple greedy approach produces good results in our experiments. We plan to 
investigate the possibility to adapt advanced dynamic node labeling algorithms, e.g. m, 
in GraphMaps. 
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5.3 Pre-rendered tiles. 

For a tile T-^ we consider the set tfj = {veV\Ln: center(i;) G T-j}. If the number 
of elements of is greater than a specific threshold, 60 in our setting, then the nodes 
of are rendered transparently into an image. 

GraphMaps generates tile images efficiently by using a recursion and avoiding pro¬ 
cessing each tile of each layer. Even for a graph with about 40000 nodes the tile gener¬ 
ation takes less than a minute. 

The images are loaded and unloaded dynamically by using a background thread 
to keep the visualization responsive. If, while browsing, a tile image is not found on 
the disk for tile T-^, then we create vector graphics elements for each node of tfj. 
GraphMaps works in such a way that not more than four tiles are loaded at a time. 
Therefore, the number of such vector elements loaded at any moment is not greater 
than 160 and they do not hinder the visualization. 



